With respect to technology in general, and to software technology in particular, it is often desirable to limit access to persons and/or entities having proper authorization, e.g., persons and/or entities having a valid license to the technology. When two components of a particular technology are utilized conjunctively to create a single user experience, for instance, when an implementation of the technology and an application exposing the technology to the user are both utilized, providing a secure validation technique to facilitate insurance of proper authorizations can be fairly easy if both components are provided by the same party (e.g., vendor). However, the mechanisms become more complex when the two components are developed by independent parties and/or if proper authorization needs to be granted by a third party.
For instance, suppose that a company licenses a technology used in software applications under the following license model: The implementation of the technology and the application exposing the technology to the user both must be licensed; the implementation and the application may be provided by different licensees; licensed applications are not to be utilized by unlicensed implementations; and licensed implementations are not to be utilized by unlicensed applications. The simple solution to facilitate insurance of proper authorizations according to this model would be for the application to validate to the implementation using a shared secret, e.g., the application may provide a password to the implementation which may then verify the password. The licensor of the technology, in this instance, would provide a list of passwords to the implementation licensee and a valid password to all application licensees that could be validated against the implementation licensee's list.
However, this solution is inadequate for a number of reasons. First, either the implementation must include a large list of passwords or a small number of passwords must be used by all possible applications. Second, if the password is intercepted as it is exchanged between the application and the implementation, it can be used by other non-licensed applications. Third, the licensor cannot issue additional passwords as the password(s) provided to the implementation licensee and the application licensee are written into the respective licensed implementation(s) and application(s).